I did not follow the change here closely. Why is this class needed?

I think we have a Rule and RuleSet class already?

With the AWS integration, details of each rule are captures as properties on the relationship between the entity and what is allowed to/from the entity.

I'm concerned that adding this will unnecessarily add more entities, which is undesired from both our perspective (data volume) and customer's (cost).

@erkangz yes, I see how this works in AWS. My concern with putting firewall rules on edges is that we cannot be as expressive on edges as we can on nodes (at least in J1QL). For example, there's not currently a way in J1QL to express direction of edges, representing ingress/egress, and edges do not allow array properties for IP addresses, ports, or protocols defined by these rules. Those are some of my main concerns when assigning firewall rules to edges.

As for creating a new class FirewallRule as opposed to using Rule, this is a pretty rare case where almost all firewall rules will share this collection of properties (sourcePort, sourceIp, destinationPort, destinationIp, protocol, action, direction), and none of these properties would be valid for almost any other type of Rule, so the distinction in my mind lends FirewallRule to its own classification.

@erkangz yes, I see how this works in AWS. My concern with putting firewall rules on edges is that we cannot be as expressive on edges as we can on nodes (at least in J1QL). For example, there's not currently a way in J1QL to express direction of edges, representing ingress/egress, and edges do not allow array properties for IP addresses, ports, or protocols defined by these rules. Those are some of my main concerns when assigning firewall rules to edges.

As for creating a new class FirewallRule as opposed to using Rule, this is a pretty rare case where almost all firewall rules will share this collection of properties (sourcePort, sourceIp, destinationPort, destinationIp, protocol, action, direction), and none of these properties would be valid for almost any other type of Rule, so the distinction in my mind lends FirewallRule to its own classification.

Valid concern. However, that's a query lang issue/limitation and I don't think we should change the data-model because of that. For direction, specifically to firewall rules, we do have ingress and egress boolean properties on the edge that can be used to filter on direction.

tldr; I would stick with the current approach until we can prove it won't work (perhaps examples from Azure or Google Cloud) and we should develop docs describing the firewall model and how to implement it.

A few thoughts:

• We can make any entity class non-billable.
• There would be number of rules X 2 more objects if we had another entity between a Firewall and the resources it relates to because of a rule (Firewall -> FirewallRule -> (Host|IpAddress|Network) vs Firewall -> (Host|IpAddress|Network)), but I think it very little data in the big scheme of things.
• We want to relate the Firewall to each (Host|IpAddress|Network) represented in a rule, so it isn't necessary for these rule relationships to support string[] properties.
• It is reasonable to anticipate we can make the query language support relationships better, though I believe we've added properties to entities in the past to get them into the index and duplicated property names to make queries look better, efforts that acknowledge it could be some time before the query language/service supports features to avoid those ingestion decisions.
• It is understandable that early decisions can make it difficult to change things now, and there would need to be good reasons to go through pains to do so.

Here are some reasons I recall that relationships were chosen.

1. Firewall rules simply define relationships between the Firewall and (Host|IpAddress|Network) entities, similar to a policy document (rules could be added as raw data of a Firewall).
2. This query reads nicely: find Host that PROTECTS Firewall that ALLOWS Internet.
3. This query reads less nice: find Host that PROTECTS Firewall that HAS Rule that ALLOWS Internet.
4. This query allows listing specific rules just fine: find Host that PROTECTS Firewall that ALLOWS as rule Network where rule.inbound=true return rule.*.

@erkangz, do you have others?

Note that there is a TypeScript type for rule relationships: